app: Fixes startup issue on newer versions of python (>=3.14)#116
app: Fixes startup issue on newer versions of python (>=3.14)#116tmagik wants to merge 1 commit intodronecan:masterfrom
Conversation
There was a problem hiding this comment.
Hi @tmagik - thanks for this PR.
I can see at some point after python 3.12.2 and 3.14.x the function get_start_method starts returning forkserver instead of None (at least on my ubuntu machine).
I've tested this change on both, it works as i would expect.
I can try help get this merged as its own changeset, but could you update:
- Rename the PR to something more in line with what you've changed - in this case, fix main from (re)setting the multiprocessing start method.
- Drop the additional commits (I understand you may be using them but they've made your PR dependent on those changes)
This is more of a conditional approval at this stage.
Thanks
|
I'm happy to help get the fix spawn changed for newer versions of python. We'll need to rebase this and drop the pkg_resource changes though. |
|
Dependent on #115 |
This fix suggested by Gemini resolves an error that occurs on some newer versions of python (specifically the one in Debian 13)
joshanne
force-pushed
the
remove_pkg_resources
branch
from
9dfc81a to
828080b
Compare
|
@tmagik i've rebased this on the latest |
joshanne
changed the title
|
Alright, so this is the difference: # Python 3.10.12
sys.version='3.10.12 (main, Mar 3 2026, 11:56:32) [GCC 11.4.0]'
multiprocessing.get_start_method(allow_none=True)=None
multiprocessing.get_start_method(True)=None
# Python 3.13.9
sys.version='3.13.9 (main, Oct 28 2025, 12:10:42) [Clang 20.1.4 ]'
multiprocessing.get_start_method(allow_none=True)='fork'
multiprocessing.get_start_method(True)='fork'
Traceback (most recent call last):
File "/home/USER/Workspace/gui_tool/bin/dronecan_gui_tool", line 60, in <module>
from dronecan_gui_tool.main import main
File "/home/USER/Workspace/gui_tool/dronecan_gui_tool/main.py", line 77, in <module>
multiprocessing.set_start_method('spawn')
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
File "/home/USER/.local/share/uv/python/cpython-3.13.9-linux-x86_64-gnu/lib/python3.13/multiprocessing/context.py", line 247, in set_start_method
raise RuntimeError('context has already been set')
RuntimeError: context has already been setIgnore the line numbers, since I have additional debugging in there - but the error is there - newer versions of python have multiprocessing start method to be I think it may be sufficient to start multiprocessing if it is not set, but if it is set, then continue without attempting to restart it. |
3 participants
This adds to #115 and fixes a startup issue on Debian 13 (and probably recent fedora as well)